Testing Network Isolation

Overview

In this lab, I will be testing the isolation of my WAN, LAN1 (networking LAN), and LAN2 (malware LAN) to ensure that the networking LAN can reach the WAN and access the internet, but the malware LAN is fully isolated and cannot communicate with any other LAN or the WAN.

Pre-Configuration Status

Before making any changes in OPNsense, I wanted to test how each LAN was behaving with the others. To do this, I created a Debian OS virtual machine on the malware LAN to see if my networking LAN could ping it. Upon pinging my networking LAN (ping 10.10.10.173) from the malware LAN VM, no packets were returned, meaning no connection. However, when pinging the malware LAN (ping 10.66.66.10) from my networking LAN, packets were successfully returned. This is a significant security issue. Traffic originating from the networking LAN was able to reach the malware LAN, creating a potential attack path from isolated machines back to outside network connections. Due to the way replay attacks and sophisticated C2 (Command and Control) malware can function, I want to ensure there is no connection at all and a near zero risk of escape.

Networking LAN (LAN1) successfully reaching Malware LAN (LAN2)

Malware LAN IP address confirmed at 10.66.66.10

With LAN1 able to reach LAN2 but LAN2 unable to reach LAN1, I opened OPNsense on my networking LAN (LAN1) web browser and began configuring firewall rules. To ensure that both LANs and the WAN have no chance of communicating with each other inappropriately, I implemented rules on both the LAN (networking lab) interface and the OPT1 (malware lab) interface.

Configuring the LAN Firewall Rule

For the LAN interface rules, configure a new rule with the following settings:

• Action — Block
• Interface — LAN
• Direction — In
• Protocol — Any
• Source — LAN network
• Destination — OPT1 network
• Log — Yes (note: this may generate a high volume of log entries; consider disabling if logs become excessive)
• Category — Any name you prefer
• Description — Any description you prefer

LAN interface

OPT1 interface

LAN rule configuration details

LAN block rule saved and ready to apply

Configuring the OPT1 Firewall Rule

I also implemented rules on the OPT1 (malware LAN) interface to ensure that any chance of outbound communication is completely cut off. Navigate to the OPT1 interface in OPNsense and create a rule with the following options:

• Action — Block
• Interface — OPT1
• Direction — In
• Protocol — Any
• Source — OPT1 network
• Destination — Any
• Log — Yes (same note as above — monitor log volume and disable if needed)
• Category — Any name you prefer
• Description — Any description you prefer

OPT1 block rule

OPT1 block rule saved

Testing Connectivity After Rule Changes

Once the new rules are saved and applied, connectivity can be re-tested using the ping command. I re-pinged the malware LAN (ping 10.66.66.10) from my networking LAN (10.10.10.173) and all packets were dropped. I also ran a reverse ping from the malware LAN to the networking LAN and confirmed those packets were dropped as well. To verify that WAN connectivity was fully blocked on the malware LAN, I also pinged 192.168.1.123 (the home router) from the malware LAN VM and received no response. The final check was opening a web browser on both LANs. The networking LAN was still able to reach the internet normally, while the malware LAN VM could not ping anything and could not reach the internet through WAN.

Networking LAN to Malware LAN — all packets dropped

Malware LAN to Networking LAN — all packets dropped

More testing

Malware LAN cannot reach WAN (192.168.1.123)

Networking LAN browser test — internet access still working correctly

Malware LAN browser test

Closing Notes

Overall, this was a straightforward lab exercise, but it was absolutely critical for ensuring the environment is secure before moving on to more advanced projects. The goal is to leave as few gaps open as possible before introducing any potentially harmful software or malware samples into the lab.

The only real challenge I encountered was with rule hierarchy in the OPNsense web GUI. I assumed that newly created rules were automatically placed at the top of the rule list, however, this was not the case. Because the default "allow all connections" rule in the LAN interface was listed above my new block rule, my block rule was being overridden. Interestingly, the OPT1 block rule did not override the LAN's "allow all" rule either, so traffic was still getting through. Once the rule order was corrected and the block rule was moved to the top, the isolation worked as intended.